The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Computer application programs executing in software containers are now widely used to deploy large-scale services for large numbers of client computers. In such a containerized services context, an enterprise may publish a container image for execution on an infrastructure provider's infrastructure, such as a cloud computing platform. A key problem in this context is permitting execution of applications only by authorized computers.
Existing security efforts in the containerized services have focused on protecting the underlying infrastructure such a host, storage, and network services. Most of these efforts focus on protecting the kernel, restricting namespaces and resources, minimizing the daemon attack surface, whitelisting container privileges, and providing hardening services to the system infrastructure. Likewise, additional security efforts have focused on trusting the container images, scanning the container libraries, and finally asserting managed secrets passed to the container. These broad-based privileges are user-based in the sense that they verify that a particular user has privileges to perform actions on the host infrastructure, or the underlying security of the internal content of the containers themselves.
However, there is no process in place for the authorization of any specific instance of a container image. This is a significant gap in a trust model in which an enterprise wants to trust any newly instantiated container. There is nothing inherently in the container that uniquely identifies the instance as trustworthy, except any parameters passed by the infrastructure provider's managed secrets. This is inherently untrusted, as the enterprise may not want to provide any secrets or credentials to the infrastructure provider.
Thus, what is need is system of validating, by an enterprise, newly created container instances without relying on the host infrastructure provider or the passage of managed secrets between the enterprise and the host infrastructure provider.
While each of the figures illustrates a particular embodiment for purposes of illustrating a clear example, other embodiments may omit, add to, reorder, and/or modify any of the elements shown in the figures.